Database system with multiple layer distribution

ABSTRACT

Method and system for accessing subscriber data in a telecommunication system, and providing a database system with a master database and slave databases acting as memory caches located with requester applications. The method including: configuring data clusters at the master database, each data cluster identifying subscriber data associated with an operation and assigned a priority; determining at the master database the priority of the data cluster associated with a received operation; and either providing the data cluster associated with the operation from the master database towards the slave database, replicating the received data cluster at the slave database, and executing the operation with the received data cluster at the slave database, where the priority of the data cluster is higher than for previous operations; or executing the operation with the data cluster at the master database, where the priority of the data cluster is lower than for a previous operation.

This application is the U.S. national phase of International ApplicationNo. PCT/EP2007/057566 filed 23 Jul. 2007, which designated the U.S., theentire contents of which is hereby incorporated by reference.

TECHNICAL FIELD

The technology disclosed herein generally relates to database systemsand, in particular, to database systems with a plurality of databasesdistributed in different locations and accessible by differentapplications.

BACKGROUND

Regarding database technologies, the concept of distributed databaseshas been widely spread for some time in order to address scalabilityissues. A distributed database may be regarded as a plurality ofdatabases physically or logically distributed, likely under control of acentral database management system, and wherein storage devices are notall necessarily attached to a common CPU. Thus, the distributed databasemight be built up with multiple computers located in the same physicallocation, or may be dispersed over a network of interconnectedcomputers. Generally speaking, the distribution of databases instancesis not necessarily a consequence of data distribution itself but alsofor the purpose of data replication in order to obtain high availablesystems.

Where considering a database system distributed in different physicallocations, one has to take into account the different nature of theapplications allowed to access such database system in terms of itsconnections to particular database instances and respective distances,as well as in terms of the data distribution amongst said particulardatabase instances. In this respect, and depending on particular modelsof data distribution to apply, one may distinguish between localapplications, which are connected to a specific database instance havingall required data and which do not required data from remote databaseinstances, and global applications, which is connected to any databaseinstances and which requires data from remote database instances.

Even where local and global applications concurrently coexist to accessthe distributed database system, and particularly where the local andglobal applications carry out communication functions between networknodes of a telecommunication network, the distributed database system isgenerally required to accomplish: a transparent distribution, so thatthe applications interact with the distributed database system as if itwere one compact logical system; and transparent transactions, so thateach transaction maintains a database integrity across the plurality ofdistributed databases.

The transparent distribution, where the plurality of databases isdistributed in different locations, requires a similar performance forlocal applications requesting data from a closely located database andfor global applications requesting data from a far away locateddatabase. This is achieved in a traditional distributed database systemby the usage of memory caches in areas closely located with therequester applications. Each memory cache temporary saving data usableby the closely located applications.

On the other hand, where memory caches are provided in areas closelylocated with the requester applications, the integrity of the databasesystem to be maintained by each transparent transaction, as one compactlogical system, requires an updating of all the memory caches each timea transaction modifies data in any particular memory cache.

In other words, where a database system with a two-layer distribution isprovided, that is, with a master database, which may be distributed in anumber of database instances or just being a centralized instance, andwith a plurality of slave databases acting as memory caches and providedin areas closely located with the requester applications, there is aneed for a sort of cache management logic that takes care about managingdata in the slave databases, managing consistency between cached data inthe slave databases and master data in the master database, and managingconsistency between different caches in different instances of the slavedatabase.

Nowadays, different mechanisms are known to address these three previousissues. For instance, the issue of managing data to be cached in theslave database may be addressed by cache algorithms like a so-called“Least Recently Used”, a so-called “Least Frequently Used”, and thelike; whereas managing consistency between cached data in the slavedatabases and master data in the master database, as well as betweendifferent caches in different instances of the slave database, may beaddressed by cache coherence models. Regarding the cache coherencemodels, the most widely known are the so-called “directory-based”,“snooping” and “snarfing”. These tree models, where applied to thetwo-layer DB architecture presented above, have different consequences.

Regarding the directory-based cache coherence model, there is adirectory entry for each data block to be cached which containsinformation about the caching state of the data block in the system, andthe locations of the slave database caching said data block. By checkingthe state and the locations, one can determine which instances of theslave database need to be updated for an operation in order to maintaincoherence.

Regarding the snooping cache coherence model, at each slave databaselocation, there is a monitor that is aware about changes in data cachedin other locations of the slave database. Where these changes takeplace, the monitor removes the cache data.

Regarding the snarfing cache coherence model, at each slave databaselocation, there is a monitor that is aware of changes in the masterdatabase and the monitor updates the cached data where there is a changein the master database.

These three models, and corresponding implementation mechanisms, arevery inefficient where the distributed database system is used in a WideArea Network (hereinafter WAN) and is shared in a telecommunicationsystem by a number of possibly different subscriber register front-ends,such as Home Subscriber Server (HSS) front-ends and Home LocationRegister (HLR) front-ends may be. In such scenario, the distributeddatabase system is expected to provide almost real time responses aswell as real time coherence whilst the slave database locations aregeographically separated by long distances, however, the WAN delaysadversely affect continuous replications and updates.

SUMMARY

The technology disclosed herein is aimed to obviate at least some of theabove disadvantages and provides for a database system with a masterdatabase and a plurality of slave databases to act as memory caches,each slave database connected with a number of applications allowed torequest execution of an operation to the database system, and for amethod of handling subscriber data in said database system. The databasesystem and the method incorporating features to allow effectivereplication and updating mechanisms where applied in a WAN and shared ina telecommunication system such as a cellular network or an IPMultimedia Subsystem (hereinafter IMS) network.

Thus, in accordance with a first aspect of the technology disclosedherein, there is provided a method of handling subscriber data in adatabase system with a master database and with a plurality of slavedatabases intended to act as memory caches, wherein each slave databaseis connected with a number of applications allowed to request executionof an operation to the database system. This method comprises theconventional steps of receiving an operation request for a givensubscriber from an application, and returning the execution resulttowards the requester application.

The method also includes, in accordance with this first aspect of thetechnology disclosed herein a step of configuring so-called dataclusters at the master database, wherein each data cluster identifies anumber of subscriber data associated with an operation and each datacluster is assigned a priority per slave database, per application, orper combinations thereof; a step of determining at the master databasethe priority of the data cluster associated with the received operation;and either the steps of providing the data cluster associated with theoperation from the master database towards the slave database,replicating the received data cluster at the slave database, andexecuting the operation with the received data cluster at the slavedatabase, where the priority of the data cluster is higher than forprevious operations; or the step of executing the operation with thedata cluster at the master database, where the priority of the datacluster is lower than for a previous operation.

Regarding the priority assigned to each data cluster, the method maycomprise a further step of dynamically updating the priority assigned tothe data cluster, the update based on accountability of successful orunsuccessful movements of the data cluster from one slave database toone another and reaching a predefined threshold value for the successfulor unsuccessful movement. This step is useful where a fine tune isfetched to accommodate each replicated data cluster in the most suitableslave database.

In particular, where the data cluster had been replicated in other slavedatabase for a previous operation, the method may include a step ofinstructing the previous slave database the removal of a data clusterwhere the priority of the data cluster at said slave database is lowerthan for a new operation. Moreover, where the data cluster is modifiedas a result of executing the operation at the slave database, the stepof executing the operation with the received data cluster may include astep of updating the master database with the modified data cluster.Furthermore, where the data cluster is modified as a result of executingthe operation at the master database, the step of executing theoperation with the data cluster at the master database may include astep of updating another slave database with the modified data cluster.

This method is particularly advantageous where the step of receiving theoperation request for a given subscriber is carried out at a slavedatabase connected with the application, since the slave databases arepreferably located in a location close to the requester applications. Insuch a case, and even more advantageously where the method furtherincludes a step of determining that no data cluster associated with theoperation exists at the slave database, the method may further include astep of sending the operation request for the given subscriber from theslave database towards the master database.

The method may include alternative steps to the step of sending theoperation request towards the master database. In this respect, themethod may include an additional step of configuring data clusters atthe slave database, wherein each data cluster identifies a number ofsubscriber data associated with the operation; and, additionally, themethod may further include a step of requesting a data clusterassociated with the operation request for the given subscriber from theslave database towards the master database.

On the one hand, the step of returning the execution result towards therequester application, in this method, may be carried out at the slavedatabase connected with the application. On the other hand, this step ofreturning the execution result towards the requester application mayinclude a step of returning the result from the master database to theslave database and a step of returning the result from the slavedatabase towards the requester application.

The method may be applicable in a database system having a uniquecentralized master database as well as in a database system wherein themaster database comprises a plurality of interconnected cooperatingdatabases. For the latter, the method may further comprise a step ofdetermining a first cooperating database in charge of the data cluster,and a step of providing either the data cluster or the result ofexecuting the operation towards a slave database through a secondcooperating database.

In accordance with a second aspect of the technology disclosed herein,there is provided a database system storing subscriber data forsubscribers of a telecommunication network, and comprising: a masterdatabase; a plurality of slave databases to act as memory caches, eachslave database connected with a number of applications allowed torequest execution of an operation to the database system; a receiver forreceiving an operation request for a given subscriber from anapplication; and a sender for returning the execution result towards therequester application.

In this database system, the master database and the plurality of slavedatabases are improved in accordance with this second aspect of thetechnology disclosed herein to accomplish the above method.

Thus, the master database includes a configuration unit for configuringdata clusters, each data cluster identifying a number of subscriber dataassociated with an operation and assigned a priority per slave database,application, or combinations thereof; a memory module for storing datacluster values per subscriber basis; a processing unit for determiningthe priority of the data cluster associated with the operation, and forexecuting the operation with the data cluster where the priority of thedata cluster is lower than for a previous operation; and a sender forproviding the data cluster associated with the operation towards theslave database where the priority of the data cluster is higher than forprevious operations. Apart from that, each slave database includes amemory module for replicating a number of data clusters from the masterdatabase; a receiver for receiving the data cluster associated with theoperation from the master database; and a processing unit for executingthe operation with the received data cluster.

Regarding the priority assigned to each data cluster, the processingunit of the master database in cooperation with the configuration unitmay be arranged for dynamically updating the priority assigned to thedata cluster. This update may be based on accountability of successful,or unsuccessful, movements of the data cluster from one slave databaseto one another and reaching a predefined threshold value for thesuccessful, or unsuccessful, movement.

In particular, where the data cluster had been replicated in other slavedatabase for a previous operation, the processing unit of the masterdatabase in cooperation with the sender may be arranged for instructinga slave database the removal of a data cluster where the priority of thedata cluster at the slave database is lower than for a new operation,and the processing unit of the slave database in cooperation with thereceiver may be arranged for removing said data cluster from the memorymodule at the slave database. Moreover, where the data cluster ismodified as a result of executing the operation at the slave database,the processing unit in cooperation with a sender of the slave databasemay be arranged for submitting an update towards the master databasewith the modified data cluster, and the processing unit of the masterdatabase in cooperation with the receiver is arranged for updating saiddata cluster in the memory module. Furthermore, where the data clusteris modified as a result of executing the operation at the masterdatabase, the processing unit of the master database in cooperation withthe sender is arranged for submitting an update towards a slavedatabase, and the processing unit of each slave database in cooperationwith the receiver is arranged for updating said data cluster in thememory module.

As advantageous as for the above method, the receiver of each slavedatabase may be arranged for receiving the operation request for a givensubscriber from the application, since the slave databases arepreferably located in a location close to the requester applications. Insuch a case, and even more advantageously where the processing unit ofeach slave database is arranged for determining that no data clusterassociated with the operation exists in the memory module at the slavedatabase, each slave database may include a sender for sending theoperation request for the given subscriber towards the master database,and the master database may further include a receiver for receivingsaid operation request.

Alternatively to the sending of the operation request towards the masterdatabase, each slave database may include a configuration unit forconfiguring data clusters at the slave database, each data clusteridentifying a number of subscriber data associated with the operation.In this case, each slave database may include a sender for requesting adata cluster associated with the operation request for the givensubscriber towards the master database.

Regarding the return of the execution result towards the requesterapplication, each slave database may include the sender for returningthe execution result towards the requester application. On the otherhand, the sender of the master database may be arranged for returningthe execution result towards the slave database, the receiver of theslave database may be arranged for receiving said result, and the senderof the slave database may be arranged for returning said result towardsthe requester application.

This database system may be provided with an arrangement having a uniquecentralized master database as well as with an arrangement having aplurality of interconnected cooperating databases where data clustersmay be distributed. In the latter arrangement, the sender of eachcooperating database may be arranged for providing either the datacluster or the result of executing the operation towards the slavedatabase directly of through another cooperating database.

In accordance with a third aspect of the technology disclosed herein,the database system described above is usable in a sort of data layeredarchitecture and can be shared amongst a number of front-end servers toprovide external communications towards other entities in atelecommunication network.

For instance, a Home Location Register (hereinafter HLR) holdingsubscriber data for subscribers of a GSM network, may comprise afront-end server for external communications and the above databasesystem, in accordance with the second aspect of the technology disclosedherein, for storing the subscriber data for said subscribers.

Also for instance, a Home Subscriber Server (hereinafter HSS) holdingsubscriber data for subscribers of an IP Multimedia Subsystem(hereinafter IMS) network, may comprise a front-end server for externalcommunications and the above database system, in accordance with thesecond aspect of the technology disclosed herein, for storing thesubscriber data for said subscribers.

The technology disclosed herein may be practised by one or more computerprograms, which may be loadable into an internal memory of a computerwith input and output units and with a processing unit, the one or morecomputer programs comprising executable software, which may be separablein different portions, adapted to carry out the above method steps inthe above different entities, server or devices, when running in anumber of computers. In particular, the executable software, or portionsthereof, may be recorded in a carrier readable medium.

BRIEF DESCRIPTION OF THE DRAWINGS

The features, objects and advantages of the technology disclosed hereinwill become apparent by reading this description in conjunction with theaccompanying drawings, in which:

FIG. 1 is a basic block diagram illustrating a database system having acentralized master database and a plurality of slave databases closelylocated to a number of applications connected to said slave databases.

FIG. 2 is a basic block diagram illustrating a database system having anumber of cooperating databases acting as a master database, and aplurality of slave databases closely located to a number of applicationsconnected to said slave databases.

FIGS. 3 a, 3 b and 3 c illustrate alternative embodiments for assigninga priority to data clusters per slave database, application requestingan operation, and combinations thereof.

FIG. 4 illustrates an exemplary table held at the master database of thedatabase system, and dynamically updated during operation, to indicatethose particular data clusters replicated in given slave databases andhaving a given priority.

FIG. 5 is a basic sequence diagram illustrating the retrieval of a datacluster for executing an operation request at a slave database where thepriority of the operation is higher than for previous operations.

FIG. 6 is a basic sequence diagram illustrating the execution of anoperation request at the master database where the priority of a newoperation is lower than for a current operation.

FIG. 7 is a basic block structure presenting the structural elementsthat a master database and a slave database may comprise in accordancewith several embodiments of the technology disclosed herein.

DETAILED DESCRIPTION

The following describes some preferred embodiments for a method ofhandling subscriber data in a database system with a master database 1and with a plurality of slave databases 2 m, 2 n, 2 p, 2 q to act asmemory caches, as illustrated in FIG. 1 and FIG. 2, each slave databaseconnected with a number of applications 3 a, 3 b, 3 c, 3 d, 3 f allowedto request execution of an operation to the database system; as well asembodiments of the database system illustrated in FIG. 7.

An important aspect behind this technology disclosed herein is theconfiguration of subscriber data as data clusters, wherein each datacluster represents an optimal amount of subscriber data associated witheach particular operation to be requested from any application. Thelevel of granularity selected for each data cluster is another importantaspect for the purpose of the technology disclosed herein and can,nevertheless, be adjusted during operation based on differentperformance measures obtained with previous values.

Therefore, this method includes an initial step of configuring dataclusters at the master database 1, wherein each data cluster identifiesa number of subscriber data associated with an operation and whereineach data cluster is assigned a priority per slave database, perapplication, or per combinations thereof. In this respect, FIG. 3 ashows a first exemplary configuration wherein each exemplary datacluster 103 a is assigned a priority 102 a per each application 101 aallowed to request execution of an operation to the database system;whereas FIG. 3 b shows a second exemplary configuration wherein eachexemplary data cluster 103 b is assigned a priority 102 b per each slavedatabase 104 b to act as memory cache; whereas FIG. 3 c shows a thirdexemplary configuration wherein each exemplary data cluster 103 c isassigned a priority 102 c per each slave database 104 c to act as memorycache and per each application 101 c allowed to request execution of anoperation to the database system.

To this end, as FIG. 7 illustrates, the master database 1 includes aconfiguration unit 10 for configuring data clusters 103 a, 103 b, 103 c,wherein each data cluster identifies a number of subscriber dataassociated with an operation and is assigned a priority 102 a, 102 b,102 c per slave database 104 b, application 101 a, or combinationsthereof 101 c, 104 c; and also a memory module 11 for storing datacluster values per subscriber basis.

Once data clusters are configured in the master database 1, the FIG. 5illustrates a basic sequence of actions carried out in accordance with afirst embodiment of the method wherein an operation associated with ahigh-priority data cluster is requested to the database system during astep S-100. Such operation is referred to, for the sake of simplicity,as a “Read/Write Operation” to indicate that the data cluster valuesmight be modified as a result of executing a ‘write operation’, and arenot modified as a result of executing a ‘read operation’. Nevertheless,these operations may always require a process rather than a simple reador write instruction in order to produce a result.

In this first embodiment, the operation for a given subscriber issubmitted from a first application 3 a, namely Application-1, during thestep S-100 and is received at first slave database 2 m, namely SlaveDB-1. Generally speaking, the database system may have a common receiverfor receiving operations from the applications. However, in accordancewith an advantageous embodiment, this step S-100 of receiving theoperation request for a given subscriber is carried out at a slavedatabase 2 m, which is connected with the first application 3 a. To thisend, as FIG. 7 illustrates, the slave database 2 m may include areceiver 21 arranged for receiving the operation request for a givensubscriber from the application 3 a.

In this first embodiment illustrated in FIG. 5, the slave database 2 mreceiving the operation searches during a step S-105 whether a datacluster associated with the received operation exists at the slavedatabase, and determines during a step S-110 that no such data clusterexists therein. Such data cluster is not replicated at the slavedatabase 2 m and actions are required from the master database 1 toobtain an execution result to be returned towards the requesterapplication. To this end, as FIG. 7 illustrates, the slave database 2 mincludes a memory module 20 for replicating a number of data clustersfrom the master database 1, and a processing unit 22 arranged fordetermining whether a data cluster associated with the operation existsin the memory module at the slave database.

In this respect, the method may further include a step S-115 of sendingthe operation request for the given subscriber from the slave database 2m towards the master database 1, as FIG. 5 illustrates. Alternatively orcomplementary, and not illustrated in any drawing, the method mayinclude a step of configuring data clusters at the slave database 2 m,each data cluster identifying a number of subscriber data associatedwith the operation and, additionally, a step of requesting the datacluster associated with the operation request for the given subscriberfrom the slave database 2 m towards the master database 1. To this end,as FIG. 7 illustrates, the slave database 2 m may include a sender 23for sending the operation request for the given subscriber towards themaster database 1, and the master database 1 may further include areceiver 14 for receiving said operation request. Alternatively orcomplementary, the slave database 2 m may include a configuration unit24 for configuring data clusters at the slave database 2 m, wherein eachdata cluster identifies a number of subscriber data associated with theoperation and, additionally, the slave database 2 m may include a sender23 for requesting a data cluster associated with the operation requestfor the given subscriber towards the master database 1.

Whatever previous alternative is followed, the method illustrated inFIG. 5 continues with a step S-120 of determining at the master database1 the priority of the data cluster associated with the operation. Tothis end, as FIG. 7 illustrates, the master database 1 includes aprocessing unit 12 for determining the priority of the data clusterassociated with the operation. This may be achieved by consulting anytable built up as the exemplary tables in FIG. 3 a, 3 b, or 3 c, or thelike.

In this case illustrated in FIG. 5, the processing unit 12 determinesduring a step S-125 that the priority of the data cluster associatedwith this new operation is higher than for previous operations, if any,and triggers the replication of the data cluster towards the slavedatabase currently in charge of the operation. Thus, the method includesa step S-130 of providing the data cluster associated with the operationfrom the master database 1 towards the slave database 2 m, a step ofreplicating the received data cluster at the slave database 2 m, and astep S-140 of executing the operation with the received data cluster atthe slave database 2 m. To this end, as FIG. 7 illustrates, the masterdatabase 1 includes a sender 13 for providing the data clusterassociated with the operation towards the slave database 2 m where thepriority of the data cluster is higher than for previous operation;whereas the receiver 21 of the slave database 2 m is arranged forreceiving the data cluster associated with the operation from the masterdatabase 1, and the processing unit 22 of the slave database 2 m isarranged for executing the operation with the received data cluster.

Particular applicable in this case, where the data cluster is modifiedat the slave database 2 m as a result of executing the operation duringthe step S-140, the method may include a step of updating the masterdatabase 1 with modified data cluster values. To this end, as FIG. 7illustrates, the processing unit 22 in cooperation with the sender 23 ofthe slave database 2 m is arranged for submitting an update towards themaster database 1 with modified data cluster values, where the receiveddata cluster is modified as a result of executing the operation, and theprocessing unit 12 of the master database 1 in cooperation with thereceiver 14 is arranged for updating said data cluster in the memorymodule 11.

Once the data cluster has been submitted for replication at the slavedatabase, the master database may update during a step S-135 a dynamictable, such as the exemplary one shown in FIG. 4, to track in whatparticular slave database 104 a particular data cluster 103 isreplicated and with what priority was submitted there. This update maybe done by the processing unit 12 of the master database 1, likelyacting on the memory module 11 therein.

In particular, where the data cluster associated with the new operationhad been previously replicated in another slave database 2 p, namelySlave DB-3, and the priority of the data cluster at the another slavedatabase 2 p is lower than for the new operation, the method may includea step S-128 of instructing the another slave database 2 p the removalof a data cluster. To this end, as FIG. 7 illustrates, the processingunit 12 of the master database 1 in cooperation with the sender 13 isarranged for instructing a slave database 2 p the removal of a datacluster where the priority of the data cluster at the slave database 2 pis lower than for a new operation, and the processing unit 22 of theslave database 2 p in cooperation with the receiver 21 is arranged forremoving said data cluster from the memory module 20.

As already commented above, the method may be enhanced with anadditional mechanism to dynamically update the priority assigned to dataclusters during the step of configuration. This update may be based onaccountability of successful, or unsuccessful, movements of the datacluster from one slave database to one another, and reaching apredefined threshold value for the successful or unsuccessful movement.For instance, in the present embodiment, the method may include a stepof increasing a so-called ‘successful counter’ for the priority assignedto the data cluster submitted to the slave database 2 m, or a step ofdecreasing the ‘unsuccessful counter’ for the priority assigned to thedata cluster withdrawn from the slave database 2 p, or both, untilreaching a predefined threshold high-value or low-value, where thecorresponding assigned priority is increased or decreased. To this end,as FIG. 7 illustrates, the processing unit 12 of the master database 1in cooperation with the configuration unit 10, the memory module 11 orboth, is arranged for dynamically updating the priority assigned to thedata cluster, the update based on accountability of successful orunsuccessful movements of the data cluster from one slave database toone another and reaching a predefined threshold value for the successfulor unsuccessful movement.

The method, in accordance with the embodiment illustrated in FIG. 5,ends with a step S-145 of returning the execution result towards therequester application 3 a. In this first embodiment, aligned with thereception at the slave database 2 m of the operation for a givensubscriber from the application 3 a, the step S-145 of returning theexecution result towards the requester application 3 a may be carriedout at the slave database 2 m, which is connected with the application 3a. Generally speaking, the database system may have a common sender forreturning execution results towards the applications. However, inaccordance with this advantageous embodiment, as FIG. 7 illustrates, theslave database 2 m includes a sender 23 for returning the executionresult towards the requester application 3 a.

A second embodiment of this method is illustrated in FIG. 6. Once dataclusters have been configured in the master database 1, as for the abovefirst embodiment, the FIG. 6 illustrates a basic sequence of actionscarried out in accordance with this second embodiment of the methodwherein an operation associated with a low-priority data cluster isrequested to the database system during a step S-150. As before and forthe same purpose, such operation is referred to as a “Read/WriteOperation”, and may always require a process rather than a simple reador write instruction in order to produce a result.

This second embodiment has quite a few actions in common with the abovefirst embodiment and, for the sake of simplicity, those particular oralternative features for the common actions, which are enough detailedfor the first embodiment, may be partially or totally omitted for thissecond embodiment without any intention of departing from the abovedescription.

In this second embodiment, the operation for a given subscriber issubmitted from a first application 3 b, namely Application-2, during thestep S-150 and is received at a second slave database 2 n, namely SlaveDB-2. As for the previous embodiment, the database system may have acommon receiver for receiving operations from the applications. However,in accordance with an advantageous embodiment, this step S-150 ofreceiving the operation request for a given subscriber is carried out atthe slave database 2 n, which is connected with the second application 3b. To this end, as FIG. 7 illustrates, the slave database 2 n mayinclude a receiver 21 arranged for receiving the operation request for agiven subscriber from the application 3 b.

In this second embodiment illustrated in FIG. 6, the slave database 2 nreceiving the operation searches during a step S-155 whether a datacluster associated with the received operation exists at the slavedatabase, and determines during a step S-160 that no such data clusterexists therein. Such data cluster is not replicated at the slavedatabase 2 n and actions are required from the master database 1 toobtain an execution result to be returned towards the requesterapplication. To this end, as FIG. 7 illustrates, the slave database 2 nincludes a memory module 20 for replicating a number of data clustersfrom the master database 1, and a processing unit 22 arranged fordetermining whether a data cluster associated with the operation existsin the memory module at the slave database.

In this respect and as for the first embodiment, the method may furtherinclude a step S-165 of sending the operation request for the givensubscriber from the slave database 2 n towards the master database 1, asFIG. 6 illustrates. Alternatively or complementary, and not illustratedin any drawing, the method may include a step of configuring dataclusters at the slave database 2 n, each data cluster identifying anumber of subscriber data associated with the operation and,additionally, a step of requesting the data cluster associated with theoperation request for the given subscriber from the slave database 2 ntowards the master database 1. To this end, as FIG. 7 illustrates, theslave database 2 n may include a sender 23 for sending the operationrequest for the given subscriber towards the master database 1, and themaster database 1 may further include a receiver 14 for receiving saidoperation request. Alternatively or complementary, the slave database 2n may include a configuration unit 24 for configuring data clusters atthe slave database 2 n, wherein each data cluster identifies a number ofsubscriber data associated with the operation and, additionally, theslave database 2 n may include a sender 23 for requesting a data clusterassociated with the operation for the given subscriber towards themaster database 1.

Whatever previous alternative is followed, the method illustrated inFIG. 6 continues with a step S-170 of determining at the master database1 the priority of the data cluster associated with the operation. Tothis end, as FIG. 7 illustrates, the master database 1 includes aprocessing unit 12 for determining the priority of the data clusterassociated with the operation. This may be achieved by consulting anytable built up as the exemplary tables in FIG. 3 a, 3 b, or 3 c, or thelike.

In this case illustrated in FIG. 6, the processing unit 12 determinesduring a step S-175 that the priority of the data cluster associatedwith this new operation is lower than for a previous operation, andtriggers the execution of the operation at the master database 1, andwith the data cluster therein, during a step S-180. To this end, as FIG.7 illustrates, the processing unit 12 of the master database 1 isarranged for executing the operation with the data cluster where thepriority of the data cluster is lower than for a previous operation.

In particular, where the data cluster is modified as a result ofexecuting the operation during the step S-180, the method may include astep of locally updating the master database 1 with modified datacluster values. Moreover, where the modified data cluster associatedwith the new operation had been previously replicated in another slavedatabase 2 q, namely Slave DB-4, and the priority of the data cluster atthe another slave database 2 q is higher than for the new operation, themethod may include a step S-182 of updating the another slave database 2q with modified data cluster values. To this end, as FIG. 7 illustrates,the processing unit 12 of the master database 1 in cooperation with thesender 13 is arranged for submitting an update towards the another slavedatabase 2 q with modified data cluster values, where the data clustersare modified at the master database 1, and the processing unit 22 of theslave database 2 q in cooperation with the receiver 21 is arranged forupdating said data cluster in the memory module 20.

The method, in accordance with the second embodiment illustrated in FIG.6, ends with a step of returning the execution result towards therequester application 3 b. In particular, the method may include a stepS-190 of returning the execution result towards the requesterapplication 3 b from the slave database 2 n, which is connected with theapplication 3 b.

Generally speaking, the database system may have a common sender forreturning execution results towards the applications. However, in thissecond embodiment illustrated in FIG. 6, this step of returning theexecution result towards the requester application may include a stepS-185 of returning the result from the master database 1 to the slavedatabase 2 n and a step S-190 of returning the result from the slavedatabase 2 n towards the requester application 3 b.

To this end, as FIG. 7 illustrates, the slave database 2 n may include asender 23 arranged for returning the execution result towards therequester application 3 b. In particular, the sender 13 of the masterdatabase 1 may be arranged for returning the execution result towardsthe slave database 2 n, the receiver 21 of the slave database 2 n may bearranged for receiving said result, and the sender 23 of the slavedatabase 2 n may be arranged for returning said result towards therequester application 3 b.

The method, under the first or second embodiments respectivelyillustrated in FIG. 5 and FIG. 6 or combinations thereof, may beapplicable in a database system having a unique centralized masterdatabase, as shown in FIG. 1, as well as in a database system whereinthe master database comprises a plurality of interconnected cooperatingdatabases, as shown in FIG. 2. For the latter, the method may furthercomprise a step of determining a first cooperating database 1 e incharge of the data cluster, and a step of providing either the datacluster or the result of executing the operation towards a slavedatabase 2 m, 2 n through a second cooperating database 1 a, 1 c. Tothis end, this database system may be provided with an arrangement 1having a unique centralized master database as well as with anarrangement 1 having a plurality of interconnected cooperating databases1 a, 1 b, 1 c, 1 d, 1 e where data clusters may be distributed. In thelatter arrangement, the sender 13 of each cooperating database may bearranged for providing either the data cluster or the result ofexecuting the operation towards the slave database 2 m, 2 n, 2 p, 2 qdirectly of through another cooperating database.

As already disclosed above, the database system and the method, underthe first or second embodiments or combinations thereof, are usable in aso-called data layered architecture wherein a number of front-endservers, which are arranged to provide external communications towardsother entities in a telecommunication network, share the databasesystem.

A first instance of an entity in a data layer architecture may be a HLRholding subscriber data for subscribers of a GSM network, wherein theHLR comprises a front-end server for external communications and theabove database system for storing the subscriber data for saidsubscribers.

A second instance of an entity in a data layer architecture may be a HSSholding subscriber data for subscribers of an IMS network, wherein theHSS comprises a front-end server for external communications and theabove database system for storing the subscriber data for saidsubscribers.

The technology disclosed herein also provides for a computer program,loadable into an internal memory of a computer with input and outputunits as well as with a processing unit, the computer program comprisingexecutable software adapted to carry out method steps as described abovewhen running in the computer, and wherein the executable software may berecorded in a carrier readable in a computer.

The technology disclosed herein is described above in respect of severalembodiments in an illustrative and non-restrictive manner. Obviously,variations, and combinations of these embodiments are possible in lightof the above teachings, and any modification of the embodiments thatfall within the scope of the claims is intended to be included therein.

The invention claimed is:
 1. A method of handling subscriber data in adatabase system comprising a master database and a plurality of slavedatabases to act as memory caches, each slave database connected with anumber of applications allowed to request execution of operations to thedatabase system, the method comprising: configuring data clusters at themaster database, wherein each data cluster identifies subscriber dataassociated with an operation and is associated with said operation, andwherein each data cluster is assigned a priority per slave databasebasis, per application basis, or per combination of slave database andapplication basis; receiving at a slave database an operation requestfor a requested operation for a given subscriber from a requesterapplication connected with the slave database; sending the operationrequest for the requested operation from the slave database to themaster database; determining at the master database a data clusterassociated with the requested operation, and the priority assigned tothe data cluster as configured for at least one of the requesterapplication and the slave database; when the priority of the datacluster associated with the requested operation is higher thanpriorities for previous requested operations associated with the datacluster, providing the data cluster associated with the requestedoperation from the master database to the slave database, replicatingthe provided data cluster at the slave database, and executing therequested operation with the provided data cluster at the slavedatabase; when the priority of the data cluster associated with therequested operation is lower than priority for a previous requestedoperation associated with the data cluster, executing the requestedoperation with the data cluster associated with the requested operationat the master database; and, returning the execution result towards therequester application.
 2. The method of claim 1, wherein returning theexecution result towards the requester application is carried out at aslave database connected with the application,
 3. The method of claim 1,further comprising determining that no data cluster associated with therequested operation exists at the slave database.
 4. The method of claim1, further comprising configuring data clusters at the slave database,each data cluster identifying the subscriber data associated with theoperation.
 5. The method of claim 4, further comprising requesting adata cluster associated with the requested operation for the givensubscriber from the slave database to the master database.
 6. The methodof claim 1, wherein returning the result towards the requesterapplication includes returning the result from the master database tothe slave database and returning the result from the slave database tothe requester application.
 7. The method of claim 1, further comprisinginstructing the removal of the data cluster associated with therequested operation from another slave database where the priority ofthe data cluster for the another slave database is lower than for theslave database executing the requested operation.
 8. The method of claim1, wherein executing the requested operation with the provided datacluster at the slave database includes updating the master databasewhere the data cluster associated with the requested operation ismodified as a result of executing the operation.
 9. The method of claim1, wherein executing the requested operation with the data clusterassociated with the requested operation at the master database includesupdating another slave database with modified data cluster values wherethe data cluster associated with the requested operation is modified asa result of executing the operation, and where the priority of the datacluster associated with the requested operation for the another slavedatabase is higher than for the slave database receiving the operationrequest for the requested operation.
 10. The method of claim 1, whereinthe master database includes a plurality of interconnected cooperatingdatabases, and further comprising: determining a first cooperatingdatabase in charge of the data cluster; and providing either the datacluster associated with the requested operation or the result ofexecuting the operation towards a slave database through a secondcooperating database.
 11. The method of claim 1, further comprising:determining successful or unsuccessful movements of the data clusterassociated with the requested operation from one slave database to oneanother; and upon reaching a predefined threshold value for a number ofsuccessful or unsuccessful movements, dynamically updating the priorityassigned to the data cluster associated with the requested operation.12. A database system storing subscriber data for subscribers of atelecommunication network, the database system comprising: a masterdatabase; a plurality of slave databases configured to act as memorycaches, each slave database connected with a number of applicationsallowed to request execution of one or more operations to the databasesystem; and a sender for returning an execution result to a requesterapplication; wherein the master database includes: a configuration unitfor configuring data clusters, wherein each data cluster identifiessubscriber data associated with an operation and is associated with saidoperation, and wherein each data cluster is assigned a priority perslave database basis, per application, or per combination database andapplication basis; a memory module configured to store data clustervalues per subscriber basis; a receiver for receiving from a slavedatabase an operation request from a request application for a requestedoperation for a given subscriber; a processing unit configured todetermine a data cluster associated with the requested operation, andthe priority assigned to data cluster as configured for at least one ofthe requester application and the slave database, and to execute therequested operation with the data cluster associated with the requestedoperation when the priority of the data duster is lower than priorityfor a previous requested operation associate with the data cluster; anda sender configured to provide the data cluster associated with therequested operation to the slave database when the priority of the datacluster is higher than priorities for previous requested operationsassociated with the data cluster; and wherein each slave databaseincludes: a memory module for replicating a number of data dusters fromthe master database; a receiver for receiving the operation request forthe requested operation for a given subscriber from the requesterapplication, and for receiving the data cluster associated with therequested operation from the master database; a sender for sending theoperation requested from the requester application for the requestedoperation for the given subscriber to the master database; and aprocessing unit for executing the requested operation with the receiveddata cluster.
 13. The database system of claim 12, wherein theprocessing unit of each slave database is arranged for determiningwhether a data cluster associated with the requested operation exists inthe memory module at the slave database.
 14. The database system ofclaim 12, wherein each slave database includes a sender for returningthe execution result to the requester application.
 15. The databasesystem of claim 12, wherein each slave database includes a configurationunit for configuring data clusters at the slave database, wherein eachdata cluster identifies the subscriber data associated with therequested operation and is associated with said requested operation. 16.The database system of claim 15, wherein each slave database includes asender configured to request a data cluster associated with therequested operation for the given subscriber to the master database. 17.The database system of claim 14, wherein the sender of the masterdatabase is arranged for returning the execution result towards therequester application through the slave database, the receiver of theslave database is arranged for receiving said result, and the sender ofthe slave database is arranged for returning said result to therequester application.
 18. The database system of claim 12, wherein theprocessing unit of the master database in cooperation with the sender isarranged for instructing the removal of a data cluster associated withthe requested operation from another slave database where the priorityof the data cluster associated with the requested operation for theanother slave database is lower than the slave database executing therequested operation, and wherein the processing unit of the anotherslave database in cooperation with the receiver is arranged for removingsaid data cluster associated with the requested operation from thememory module.
 19. The database system of claim 12, wherein theprocessing unit in cooperation with a sender of each slave database isarranged for submitting an update to the master database where thereceived data cluster is modified as a result of executing the requestedoperation, and wherein the processing unit of the master database incooperation with the receiver is arranged for updating said data dusterassociated with the requested operation in the memory module.
 20. Thedatabase system of claim 12, wherein the processing unit of the masterdatabase in cooperation with the sender is arranged for submitting anupdate to a slave database where the data cluster is modified at themaster database as a result of executing the requested operation, andwherein the processing unit of each slave database in cooperation withthe receiver is arranged for updating said data cluster in the memorymodule.
 21. The database system of claim 12, wherein the master databaseincludes a plurality of interconnected cooperating databases where dataclusters are distributed, the sender of each cooperating database beingarranged for providing either the data cluster associated with therequested operation or the result of executing the operation towards theslave database directly or through another cooperating database.
 22. Thedatabase system of claim 12, wherein the processing unit of the masterdatabase in cooperation with the configuration unit is arranged for:determining successful or unsuccessful movements of the data clusterassociated with the requested operation from one slave database toanother; and upon reaching a predefined threshold value for a number ofsuccessful or unsuccessful movements, dynamically updating the priorityassigned to the data cluster associated with the requested operation.23. A Home Location Register system configured to hold subscriber datafor subscribers of a 2^(nd) generation cellular network, the systemcomprising: a front-end server for external communications; and thedatabase system of claim 12 for storing the subscriber data for saidsubscribers.
 24. A Home Subscriber Server system configured to holdsubscriber data for subscribers of an IP Multimedia Subsystem “IMS”network, the system comprising: a front-end server for externalcommunications; and the database system of claim 12 for storing thesubscriber data for said subscribers.
 25. A non-transientcomputer-readable memory comprising instructions which, when executed bya processor, perform the method of claim 1.